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Abstract 

This  paper  examines  group  communication  as  an  infrastructure  to  support  mobility  of  users, 
and  presents  a  simple  scheme  to  support  user  mobility  by  means  of  switching  a  control  point 
between  replicated  servers.  We  des^be  the  design  and  implementation  of  a  set  of  tools,  called 
MobileChannel,  for  use  with  the  ISIS  system.  MobileCht^el  is  based  on  a  combination  of  the 
two  replication  schemes:  the  primary-backup  approach  and  the  state  machine  approach. 
MobileChannel  implements  a  reliable  one-to-many  FIFO  channel,  in  which  a  mobile  client  sees  a 
angle  reliable  servo;  servers,  acting  as  a  state  madune,  see  multicast  messages  from  clients. 
Migrations  of  mobile  clients  are  handled  as  an  intentional  primary  switch,  and  hand-offs  or  server 
failures  are  conqiletBly  masked  to  mobile  clioits.  To  achieve  high  performance,  servers  are 
reheated  at  a  sliding-window  level.  Our  schone  provides  a  sinqrle  abstraction  of  migration, 
eliminates  conqilicated  hand-off  protocols,  provides  fault-tolerance  and  is  inqrlemented  widtin  the 
existing  group  communication  mechanism. 


1  Introduction 

Emerging  handheld  conqxiters  with  communication  capabilities  will  have  a  significant  impaa  on 
distributed  computing.  Whei^  die  traditional  distributed  systems  are  designed  assuming  a  static  netwmk 
ctmnectivity,  mobility  of  machines  in  die  system  poses  nummtnis  problems  that  need  to  be  solved.  As 
mcdnle  users  travel  around  in  a  network,  the  network  tt^logy  must  be  dynamically  reconfigured. 
Especially,  in  a  cellular  wireless  network,  users  can  travel  between  wireless  cells  v^e  maintaining 
connectivi^.  This  process,  switching  a  route  in  the  middle  of  communication,  is  called  a  fran4-<#.  Hand- 
off  requites  the  sys^  to  maintain  die  end-to-end  cminectivity  in  the  presence  of  a  dynamically  changing 
networit  topology. 

When  designing  a  complex  system,  layers  of  anqiler  abstractions  should  be  employed  not  only  for  ease 
of  design  but  also  for  performance.  Layers  need  not  be  cosdy;  a  well-defined  and  well-engineered 
infrastructure  often  performs  better  than  a  complex  flat  design.  Current  mobile  computing  technologies 
lack  sudi  layers  of  abstractions.  This  paper  examines  group  commu/ucation  as  an  infrastructure  to  support 
mobility  of  users. 

Group  communication  systms  offer  primitives  in  support  of  distributed  groups  of  cooperating 
processes.  Their  technologies  are  based  on  muldcasting  and  membership  service  [Binnan93][Amir91] 
[Cheriton8S][Kaa8hoek911.  Thou^  group  communicrUion  has  been  studied  mainly  for  fault-tolerance. 


*This  work  was  performed  at  Cornell  University,  and  was  siqipotted  under  ARPA/ONR  grant  N00014-92- 
J-1866,  and  by  a  grant  firom  Canon  Inc.  Kenjiro  Cho  is  an  employee  of  Canon,  Inc.,  currendy  visiting  the 
Dqrt.  of  Conqmter  Scioice  at  Cornell  University.  Ken  Birman  is  a  Professor  in  the  Dept,  of  Computer 
Science  at  Cornell  University,  and  Chief  Scientist  of  Isis  Disfributed  Systems,  a  division  of  Stratus 
Conqmter,  Inc.  Audiors'  e-rnsil  addresses  ate  (Iqc,  lmn}@cs.comdl.edu. 
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experience  has  demonstrated  the  approach  can  consitterably  simplify  any  distributed  program  which  needs 
coordination  among  multiple  processes. 

Group  communication  is  also  intrinsically  appealing  for  handling  mobility.  In  group  communication, 
multicast  messages  are  sent  to  abstract  groups  and  senders  do  not  need  to  know  the  members  of  the  group. 
Dynamic  group  membership  management  allows  one  to  dynamically  join  or  leave  groups.  Hence,  one  can 
leave  a  group,  then  move  to  another  place,  re-join  the  same  group  and  continue  working  with  the  other 
members.  In  this  sense,  group  communication  already  provides  location  independence  and  is  able  to  adapt 
to  a  dynamically  reconfiguring  network  topology.  Reliable  ordered  multicasting  guarantees  that  all  group 
members  will  see  the  same  set  of  messages  in  a  guaranteed  order,  so  that  synchronizing  multiple  processes 
or  coordinating  cooperative  actions  is  easy  to  achieve.  Moitovet.faub-tolerance  (a  system  can  continue  to 
work  in  the  presence  of  failures)  is  essential  part  of  group  conununication  design. 

Prior  work  related  to  host  mobility  has  focused  on  schemes  to  inqtlement  transparent  mobile  support 
in  the  network  layer  [Ioannidts91]rreraoka91].  Some  of  them  address  multicasting  as  an  effective  way  to 
improve  performance  and  reduce  the  cost  [Ioannidis91][Keeton93][Acharya93].  Hand-off  schemes  and 
protocols  from  a  higher  level  layer  are  presented  in  [^:harya94]  by  means  of  multicasting  to  mobile  hosts 
and  multicast-groups  of  mobile  hosts.  However,  these  apin-oach^  require  coiiq>licated  protocols  for 
handshaking  and  buffering,  and  fault-tolerance  is  not  ofrra  addressed. 

On  the  other  hand,  the  real  power  of  group  communication  resides  in  its  ability  to  support  consistent 
replicas,  and  a  rq)lication  mechanism  can  be  used  for  handling  mobility  of  users.  This  paper  presents  a 
simple  scheme  to  support  user  mobility,  which  is  based  on  an  abstraction  of  replicated  servers  provided  by 
group  communication.  In  our  scheme,  hand-off  is  realized  by  switching  a  control  point  between  replicated 
servers.  Our  scheme  provides  a  simple  abstraction  of  migration,  eliminates  complicated  hand-off  protocols 
and  hand-off  time,  provides  fault-tolerance  and  is  implemented  within  Ate  existing  group  communication 
medianism. 

To  demonstrate  our  approach,  we  have  devdoped  a  system  called  MobileChannel.  Our  goal  is  to 
identify  and  implement  a  suitable  tool  to  support  building  mobile  services  and  to  integrate  those  services 
into  the  existing  distributed  environments  ba^  on  groiq>  communication. 

MobileChannel  employs  server  rqilication  to  support  migration  of  mobile  clients.  A  migration  is 
realized  by  switching  a  control  point  from  one  replicat^  server  to  another  iq>licated  server.  A  one-to-many 
channel  is  implemented  between  a  client  and  servos.  A  client  sees  a  single  reliable  server  on  the  other  end 
of  Ate  channel;  hand-offs  or  server  fsilutes  are  completely  masked  to  clients.  On  the  oAxar  hand,  servers  see 
mulAcast  messages  fimn  clients  and  hold  consistmit  server  replicas  acAng  as  a  state  machine.  All  servers 
observe  a  same  set  of  incoming  messages  from  clioits  but  the  only  primary  server  actually  sends  messages 
to  the  client  A  hand-off  or  a  primary  failure  invokes  a  primary  switch  in  which  one  of  Aie  oAier  rqtlicated 
servers  takes  over  the  channel  on  die  fly.  A  hand-off  is  triggem)  by  a  single  multicast  message  to  Aie 
server  groiqi;  no  hand-off  protocol  is  necessary  betwemi  a  client  and  servers.  To  achieve  high  performance, 
servers  are  replicated  at  a  sliding-window  level;  the  slicting-window  itself  is  designed  as  a  state  machine.  On 
top  of  the  channel  mechanism,  two  types  of  communication,  a  RPC  style  and  a  "diffusion”  style,  ate 
suppmted.  These  st^es  are  designed  to  tolerate  climits  to  be  unreaiAiable  for  a  short  period,  vduch  often 
occurs  in  a  wireless  netwoilt  The  qiproach  scales  well,  imvided  AuA  the  underlying  grotp  communication 
infrastructure  scales  iqi. 

MtAiileChaniiel  is  implemented  as  libraries.  The  server  library  runs  on  top  of  ISIS  and  Aie  client 
library  does  not  require  Aiat  ISIS  itself  operates  on  Aie  mobile  computo’.  The  client  library  is  light-weight; 
Aie  current  implementation  consumes  only  130K  bytes  on  Microsoft  Windows^ .  MobileQiannel  also  can 
be  used  for  immobile  and  /  or  wired  small  computm  as  a  light-wdght  fault-tolerant  tool. 


I  All  trademarks  iqipearing  in  Aus  paper  are  recognized  registered  trademarks  of  their  reflective  conqianies. 
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Figure  1 .1  MobileChannei  Programming  Model 


MobileChannd  consists  of  two  layers:  the  mobile  view  layer  and  the  channel  layer.  Figure  1.1  shows 
the  programming  model  of  MobileChannei.  The  mobile  view  layer  in^lements  mobile  client  management 
on  the  server  side.  The  channel  layer  implements  a  communication  mechanism  between  a  server  and  a 
client.  Other  than  these  layers,  utilities  are  implemented  to  support  programming.  Figure  1.2  presents  the 
run-time  structure  of  rqilicated  servers. 


Figure  1.2  replicated  server  run>time  structure 


2  Design  of  the  MobileChannei  tool 

In  this  section,  we  presents  the  design  of  MobileChannei.  The  MobileChannei  tool  is  designed  to 
provide  continuous  services  to  mobile  clients  and  tolerate  failures  of  servers.  Services  are  available  as  long 
as  (me  of  the  smers  survives.  For  geogr^itncally-defined  wireless  cells,  ^ysical  layout  should  provide 
fault-tolerance  by  means  of  overhang  cells  or  backup  stations  so  that  a  clioit  can  reach  die  services  as 
long  as  one  of  the  reachable  servers  survives.  MobileChannei  provides  a  reliable  but  che^  communication 
means  fix’  unreliable  mobile  clients.  A  communicaticm  duumel  looks  like  an  one-to-many  cdiannel  carrying 
ISIS  st^e  messages,  and  tolerates  transitory  unreachability.  On  top  of  this  duumel,  MobileChannd 
supports  various  utilities  for  communication.  MobileChannei  manages  mobile  clients  and  provides  a 
paradigm  in  sdiich  programmers  do  not  need  to  know  the  stanis  of  clioits  or  server  failures. 
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2.1  System  Model 

The  system  consists  of  two  distinct  sets  of  computers:  static  servers  and  mobile  clients  (Figure  2.1 ). 

A  group  of  servers,  running  ISIS  on  a  static  local  area  network,  provides  services  to  mobile  clients. 

Servers  act  as  a  proxy  for  a  mobile  client.  Mobile  clients  talk  to  these  servers  through  a  wireless  channel. 
The  wireless  network  is  organized  by  geographically-defined  cells.  Mobile  clients  can  cross  the  cell 
boundaries  maintaining  communication  connectivity.  The  static  network  and  wireless  network  are 
connected  by  gateway  servers,  called  Mobile  Support  Stations  (MSS),  that  are  the  control  points  of  mobile 
clients.  Scalability  of  the  system  is  discussed  in  section  2.7. 


Figure  2.1  System  Model 


2.2  Requirements  of  Mobile  Computing 

Our  groiqi  communicatioii  platfonn  is  die  ISIS  system.  ISIS  is  a  toolkit  for  building  applications 
consisting  of  cooperating  processes  in  a  distributed  system  [Binnan93].  Group  management  and  group 
communication  are  two  basic  building  blocks  provid^  by  ISIS.  The  most  important  communication 
primitive  in  ISIS  is  CBCAST.  CBCAST  inqilements  reliable  causal  ordering  delivery  based  on  the 
potential  causality  rdationship  between  evoits  in  the  system.  Another  important  communication  primitive 
is  ABCAST.  ABCAST  inqilements  total  ordering  (every  member  observes  events  in  the  same  order)  in 
addition  to  die  properdes  of  CBCAST  [Binnan91]. 

ISIS  has  been  widely  used  for  qiplicadons  which  need  to  access  consistent  dau  scattered  over  a 
heterogeneous  network.  Many  of  tli^  applications  are  also  suitable  for  mobile  terminals  such  as  factory 
automation  systems,  stock  trading  systems,  ticket  reservation  systems  and  store  inventory  systems. 

AldMugh  ISIS  supports  a  wide  range  of  group  communication  medianisms,  ISIS  does  not  normally 
siqqiort  mobility  of  users.  Several  difficulties  arise  when  running  ISIS  on  mobile  computers. 

One  practical  impediment  for  running  ISIS  on  a  small  computer  is  that  ISIS  is  a  fairly  large  system. 
ISIS  provides  a  varimy  of  mechanisms  to  sun>ort  various  types  of  distributed  qiplications,  but  such  Inoad 
functionality  is  too  la:^  and  too  heavy  for  a  simple  client  program  on  a  small  computer. 

A  related  problem  is  diat  ISIS  runs  on  UNIX  or  mote  advanced  operating  systems  but  such  operating 
tystems  are  not  designed  for  small  mobile  computers.  Those  operating  systems  have  an  implicit 
assumption  in  the  design  that  die  workstation  will  remain  at  a  particular  location,  and  hooked  up  to  power 
and  Ediernet.  Design  modifications  to  such  operating  systems  for  suiptming  small  mobile  con^ters  need 
dabonte  engineering  efforts  [Bender93].  Among  th^  power-saving  is  die  most  serious  issue  for  battery- 
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based  computers.  People  use  bauery-based  computo^s  because  they  cannot  plug  into  the  power  source  while 
using  computers,  and  thus,  battery  life  is  critical  to  their  jobs.  Since  battery  life  will  not  improve  much  in 
the  near  future,  power  management  is  essential  to  inaeasing  the  working  time  with  limited  battery  life. 
Less  power  consuming  schemes  should  be  employed  when  possible,  and  components  or  the  entire  machine 
should  go  into  a  sleep  mode  when  it  is  idle.  However,  operating  system  design  has  been  evolving  in  favor 
of  high-performance,  and  as  a  result,  modem  operating  system  components  tend  to  consume  more  power 
and  have  difficulty  implementing  power  management  because  of  elaborate  designs,  such  as  data  caching, 
lazy  execution,  back  ground  processes,  etc.  Ironically,  a  less  sophisticated  operating  system  is  easier  to 
modify  for  power  management  and,  in  the  current  market,  has  an  advantage  with  regard  to  battery  life. 

Another  problem  is  that  the  frequently  unreachable  nature  of  mobile  devices  creates  a  communication 
model  that  contradicts  some  basic  ISIS  assumptions.  ISIS  processes  should  be  responsive  to  messages 
because  of  the  design  of  multicast  ordering  and  failure  detection.  However,  a  mobile  machine  needs  to  go 
into  a  sleep  mode  to  save  power  consumption  and  will  not  receive  messages  in  the  sleep  mode.  A  mobile 
machine  that  must  be  continuously  responsive  can  never  go  into  the  sleep  mode.  Moreover,  a  wireless 
channel  tends  to  be  temporarily  unreachable  because  of  obstacles  or  barriers  as  the  user  moves. 

ISIS  will  consider  these  transitory  communication  gaps  as  a  failure,  then  throw  the  unreachable  client 
out  of  the  group.  When  the  client  restores  communication,  it  needs  to  re-join  the  group.  These 
membership  ct^ges  are  costly  in  ISIS,  since  the  design  of  ISIS  assumes  that  a  membership  change  is 
infrequent  and  it  is  acceptable  that  membership  management  is  expensive. 

In  light  of  these  considerations,  to  apply  ISIS  to  mobile  computing  in  practical  settings,  the  system 
needs  to  provide  mechanisms  to  satisfy  a  series  of  requirements;  A  mobile  client  needs  a  very  light-weight 
tool.  In  order  to  take  advantage  of  a  power-saving  mechanism,  the  tool  should  run  on  small  operating 
sjrstems  and  it  is  desirable  that  a  client  can  start  or  stop  communication  at  any  time  without  any 
negotiation  in  order  to  go  into  the  sleep  mode.  Mobile  clients  become  frequently  unreachable  so  that  the 
system  needs  a  cheap  way  to  manage  teo^rarily  unreachable  clients.  The  system  has  to  provide  some  kind 
of  reliable  tran^xnt  mechanism  for  unreliable  clients  and  cannot  expect  any  coordination  among  unreliable 
clients  (as  oppose  to  the  "peer”  design  of  ISIS). 

2.3  Communication  Model 

The  communication  structure  assumed  by  MobileOiannel  is  that  a  mobile  client  talira  to  a  server  group 
OB  a  static  network.  ISIS  sufqports  various  types  of  group  structures  [Buman93]  but  MobileChannel 
focuses  on  two  of  than  that  are  suitable  for  mobile  applications.  One  is  RPC  communication;  the  other  is 
"diflusion”  ctHomunication.  In  the  RPC  case,  a  groiq>  of  processes  act  as  servers  on  bdudf  of  a  large  set  of 
clients.  Clients  interact  widi  the  servers  in  a  request  /  reply  style.  The  diffusion  style  is  a  type  of  client- 
server  groiQ)  in  which  the  servers  multicast  messages  to  the  full  set  of  clioits.  Qients  are  passive  and 
sinqily  recdve  messages.  A  diffusion  style  arises  in  any  implication  diat  broadcast  information  to  a  large 
number  of  sites.  These  two  types  of  communication  uyles  are  common  for  many  q)plications.  For 
exanmle,  a  trading  system  wiU  use  the  diffusimi  communication  to  disseminate  stock  quotes  and  the  RPC 
communication  to  make  stock  transactions. 

2.4  State  Machine  Approach  and  Primary-Badtup  Approach 

To  inqplonent  a  highly  available  service,  the  service  should  be  iq>licated  and  distributed  among 
mult^le  servers.  Updato  should  be  coordinated  so  that  even  when  a  server  fails,  the  service  lonains 
available.  Data  rqrlication  has  the  additional  benefit  of  performance,  by  placing  a  rqplica  at  sites  where  the 
service  is  needed.  In  genend,  ^icatitm  is  implemented  in  (»e  of  two  ways.  One  is  iht  state  machine 
sppcoach,  wbkb  has  no  centralized  contrtd  [Shneider85][Shneider93][Birman8S];  and  the  odier  is  the 
primary-bacbtp  sppmadi,  uddch  has  a  centralized  control  [Budhinya93]. 

In  the  state  madune  ^rproach,  a  client  makes  a  request  by  multicasting  to  all  savers.  All  the  servers 
change  their  states  identically  in  lock  step.  A  server  failure  is  invisible  to  clients  and  does  not  introduce 
any  response  delay.  In  die  primary-backup  approach,  a  client  makes  a  request  by  sending  a  message  only  to 
the  primary  server.  If  die  primary  server  fails,  then  ajbilover  occurs  and  one  of  the  backup  servers  takes 
over.  Requests  can  be  lost  at  a  primary  failure  and  clients  need  to  be  informed  about  the  failure  to  re-try  the 
lost  requMts,  sriiich  Introduces  a  failova  time.  In  general,  the  primary-backup  tqiproach  is  simpla  and  less 
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costly,  especially  on  the  client  side,  than  the  state  machine  approach  that  requires  reliable  ordo^ed 
multicasting. 

For  mobile  clients,  the  cheaper  mechanism  of  the  primary-backup  approach  is  more  attractive.  Clients 
do  not  need  to  implement  multicasting  that  may  be  considerably  more  complicated  than  a  point-to-point 
communication.  In  addition,  mobile  clients  in  a  cellular  wireless  network  can  reach  a  limited  number  of 
servers  within  the  communication  range  so  that  multicasting  to  all  servers  may  not  be  possible. 

On  the  other  hand,  ISIS  supports  the  state  machine  ^proach  and  provides  a  sophisticated  prograimning 
paradigm  in  which  programs  take  actions  according  to  events.  The  state  machine  ^proach  is  more  flexible 
for  several  reasons:  the  mechanism  is  completely  decentralized,  a  program  can  take  actions  only  from  its 
local  state,  clients  can  expect  real-time  responses  even  in  the  presence  of  failures,  the  system  can  tolerate 
arbitrary  failures. 

MobileChannel  employs  a  combination  of  the  two  schemes:  the  primary-backup  apin-oach  between  a 
client  and  servers  and  the  state  machine  approach  among  servers.  Figure  2.2(a)  shows  the  channel  structure 
of  MobileChannel.  A  client  talks  only  to  a  primary  but  the  primary  forwards  incoming  messages  to 
backups  in  order  to  provide  an  illusion  that  the  client  has  a  multicasting  c^ability  (Figure  2.2(b)).  This 
allows  programmers  to  utilize  the  state  machine  approach  on  the  server  side.  From  programmers'  point  of 
view,  clients  see  a  reliable  channel  and  primary  failures  are  unnoticeable.  Server  side  programming  is  based 
on  the  state  machine  iqiproach  similar  to  the  ISIS  model  and  the  primary-backup  mechanism  is  hidden  in 
MobileChannel. 


(«)  client  talks  to  primaiy  (b)  primaiy  forwards  tnsg  to  backups 

Figure  2.2  primary-backup 


2^  Migration  as  an  Intentional  Primary  Switch 

The  most  unique  feature  of  MobileChannel  is  dial  migrations  of  mobile  clients  are  handled  as  an 
intentional  primary  switdi.  In  the  primary-backup  approach,  a  failover  usually  occurs  only  at  a  i»imary 
failure.  However,  this  same  mechanism  can  be  u^  for  a  migration  control  in  order  to  move  the  primary  to 
a  neaiby  backiqp.  E^iedally  in  a  cellular  wireless  network,  diis  medumism  allows  the  system  to  place  the 
primary  within  a  desM  communication  range.  In  short,  the  primary  status  can  be  handed  over  from  one 
server  to  another  to  geognqdiically  foDow  the  user.  Rgure  2.3  shows  a  primary  switch  to  s3  fiom  s2  that 
was  primary  in  Rgure  22.  In  the  primary-baclnq>  approach,  backups  are  designed  to  take  over  a  primary  at 
any  time  in  case  of  aprimary  failure  so  dut  there  is  no  difficulty  to  invoke  a  primary  switch  at  any  time. 
The  only  difference  is  that  the  prinury  switch  is  invoked  not  by  a  primaiy  failure  but  by  a  migration  of  a 
mobile  client 
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Figure  2.3  migration  as  an  intentional  primary  switch 


2.6  Sliding'Window  Replication 

Synchronization  mechanism  is  necessary  for  any  communication.  When  multiple  processes  need  to 
synchronize,  a  handshake  of  two  processes  introduces  a  handshake  time,  and  thus,  buffering  is  necessary  for 
messages  from  the  other  processes  during  this  period.  Handshaking  and  buffering  are  sources  of  the 
difficulties  of  hand-off  protocols  [Acharya94][Keeton93].  Such  hand-off  i^ocedures  require  handshaking 
among  three  parties:  a  new  server,  an  old  server  and  a  mobile  client  However,  our  scheme  does  not  need 
explicit  handshaking  at  all  but  handshaking  is  automatically  achieved  by  the  underlying  structures. 

Handshake  betweoi  servers  can  be  acceded  in  the  ISIS  virtual  synchrony  model  [Binnan93],  for  the 
following  reasons.  Virtual  synchrony  is  an  illusion  that  every  event  happens  synchronously  in  the  system. 
Events  such  as  receiving  messages  are  synchronous  in  terms  of  logical  time  (L^port78],  though  eat^ 
process  receives  a  same  message  at  differoit  physical  time.  Virtual  synchrony  can  be  us^  to  synchronize 
multiple  processes  and  release  programmers  from  {voblems  of  handshaking  and  buffering. 

MobileChannel  converts  messages  from  mobile  clients,  generated  outside  ISIS,  to  virtually 
synchronous  ISIS  events  by  forwarding  messages  from  mobile  clients  to  all  servers.  Thus,  all  servos 
observe  the  same  set  of  incoming  messages  in  the  same  order,  ti^ch  allows  servers  to  take  the  state 
machine  approach.  When  a  hand-off  of  a  mobile  clmnt  is  requested  by  multicasting  to  a  server  group,  all 
servers  can  take  appropriate  actions  without  any  handshaking.  The  ne^  for  a  handshake  between  two 
servers  can  thus  te  eliminated  by  exploiting  virtual  synchrony. 

Handshake  between  a  mobOe  client  and  servers  are  confined  to  a  low-levd  tran^ort  mechanism.  Prior 
hand-off  protocols  assume  a  FIFO  channel  between  a  server  and  a  client  [Acharya94][Keeton93].  Although 
a  pnK)  channel  is  a  useful  abstraction  for  a  static  network,  it  does  not  work  well  for  a  hand-ofr  procedure. 

The  problem  of  a  FIFO  channel  is  that  a  hand-off  procedure  needs  to  terminate  die  connection  to  the  old 
server  and  that  establidi  a  new  ctmnection  to  a  new  server.  These  two  procedures  require  handshaking 
bdween  both  ends  and  introduce  delays  and  buffering.  Furthermore,  a  channel  takeover  of  a  FIFO  channel 
is  not  faub-tolerant  When  a  server  fails,  another  server  should  take  over  the  channd  for  fault-tolerance. 
Since  there  is  no  way  in  a  FIFO  dumnel  to  know  the  state  of  the  other  party ,  e.g.,  the  last  received 
message  id,  addition^  protocols  between  the  client  and  the  new  server  are  necessary  to  restore  the  states.  A 
server  failure  in  die  middle  of  a  hand-off  will  need  further  complicated  protocols. 

However,  if  a  lower  level  of  transfer  abstraction  is  used,  such  as  packet  level,  the  communication  state 
can  be  rqdicated  on  a  per  packet  basis.  If  a  new  server  knows  the  last  packet  transferred  or  acknowledged, 
die  new  server  can  take  over  and  continue  communication  without  any  handshaking.  Moreover,  protocols 
of  this  level  already  assume  that  packets  may  get  lost  or  duplicated,  so  that  the  protocol  is  inherendy  robust 
to  packet  loss,  duplicates  or  timing  delays,  which  might  be  introduced  by  a  takeover.  Thus,  no  special 
protocol  is  necessary  for  a  hand-off,  and  explicit  handshaking  between  a  mobile  client  and  servers  can  be 
efiminated. 
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MobileChannel  implements  a  sliding-window  protocol  for  communication  between  a  mobile  client  and 
servors,  and  replicates  the  sliding-window  state  on  the  server  side.  A  sliding-window  protocol  is  used  to 
implement  a  F^O  channel  and  to  control  message  flow  in  a  communication  channel.  The  protocol  can 
nuJce  full  use  of  network  bandwidth  if  carefully  tuned,  which  is  important  especially  for  wireless 
communication  media  because  of  their  relatively  low  bandwidth.  Replicating  sliding-window  states  allows 
MobileChannel  to  achieve  high  performance  as  well  as  keeping  the  state  machine  model. 


2.7  Scalability 

Scalability  is  essential  to  a  mobile  computing  infrastructure.  The  design  of  a  mobile  support  system 
should  have  reasonable  scalability. 

A  hio'archical  group  structure  will  be  used  to  scale  up  MobileChannel.  When  a  service  needs  to  be 
available  to  hundreds  of  mobile  users  at  tens  of  sites,  it  is  desirable  to  replicate  the  service  at  each  site  but 
replicate  the  state  of  a  client  only  at  a  small  subset  of  sites.  Such  a  group  will  be  structured  in  the  way  that 
the  group  of  the  service,  which  consists  of  the  whole  sites,  has  subgroups;  each  subgroup  corre^onding  to 
a  mobile  user.  Each  user  subgroup  consists  of  neighbor  sites  of  the  current  location  of  the  user.  Figure 
2.4(a)  shows  an  example  of  site  layout:  each  box  represents  a  site  and  the  whole  sites  constitute  a  service 
group.  The  shadowed  sites  form  a  subgroup  around  the  black  primary  site  where  a  user  currently  resides. 

Dynamic  group  membership  can  support  user  mobility.  The  idea  is  that  a  subgroup  moves  along  a 
user  as  a  flock.  As  a  user  travels,  new  sites,  located  in  the  direction  the  uso*  heads  for,  join  the  subgroup. 
Then  member  sites  located  behind  the  user  leave  the  groiq>  in  order  to  keep  the  group  size.  In  Figure 
3.4(b),  the  subgroup  moves  from  3.4(a)  to  foUow  the  user.  When  a  disconnected  user  esublishes  a  new 
connection  at  a  remote  site  from  the  previous  location,  a  new  subgroup  ^outs  at  the  new  location,  and 
then,  the  old  subgroup  vanishes. 


Rgure2.4  subgroup  follows  a  user  as  a  flock 


Moreover,  sites  do  not  belong  to  any  subgroup  can  leave  the  service  group  to  reduce  the  service 
group  size.  Those  sites  will  re-join  the  service  group  v/bea  a  user  come  close  to  th^.  By  holding  only 
member  sites  of  subgroups,  die  entire  service  group  changes  the  shape  to  adi^t  to  movements  of  users. 

To  scale  the  system  up  to  thousands  or  millions  of  sites,  further  hierarchy  would  be  necessary. 
Though  the  current  group  communication  infrastructures  do  not  scale  up  to  this  level,  research  effort  into 
this  question  is  underway  [Glade92]. 
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3  Implementation 

Programming  model  of  MobileChannel  is  derived  from  ISIS  and  UNIX.  The  callback  style  of 
MobileChannel  is  similar  to  ISIS  but  does  not  require  a  thread  system.  The  ISIS  message  library 
[BirmanS?]  is  used  for  marshalling  /  unmarshalling  messages.  The  channel  connection  management  uses  a 
semantics  similar  to  the  UNIX  socket  /  TCP  model  [Lenier89]. 


3.1  Mobile  View  Layer 

The  mobile  view  layer  manages  mobile  clients.  Two  types  of  migration  are  defined;  one  is 
reconnection  and  the  other  is  hand-off.  A  reconnection  is  a  disconnected  migration  and  occurs  when  a  user 
establishes  a  new  connection.  A  hand-off  is  an  on-line  migration  and  usually  occurs  when  a  user  crosses 
the  cell  boundary.  A  hand-off  requires  a  dynamic  channel  switch. 

A  primary  failure  is  handled  as  a  migration.  A  primary  failure  can  be  a  reconnection  or  a  hand-off 
depending  on  the  channel  state  at  a  primary  failure.  If  the  channel  state  is  not  active,  the  new  primary  takes 
over  the  primary  status  but  does  nothing.  When  the  client  reconnects  to  one  of  the  servers  later,  an  ordinary 
reconnection  occurs.  On  the  other  hand,  if  the  channel  is  active  at  the  primary  failure,  a  hand-off  takes  place 
and  the  new  primary  takes  over  the  channel. 

Migration  can  be  triggered  by  requesting  a  migration  to  a  current  primary;  the  easiest  way  is 
multicasting  a  request  to  the  server  group,  another  way  is  to  request  from  a  mobile  client.  Upon  receiving  a 
migration  request,  the  primary  multicasts  a  primary  switch  command  to  the  group.  The  primary  switch 
command  uses  ABCAST  to  guarantee  that  all  servers  observe  the  command  in  the  same  order  with  regard  to 
other  messages  and  a  mobile  client  has  a  single  primary  at  one  (virtual  synchrony)  time.  Each  server  keeps 
a  consistent  (identical)  state  list  of  mobile  clients  called  a  mobile  view.  The  mobile  client  state  includes 
the  current  primary  information  and  the  channel  stidus.  When  a  client  establishes  a  connection  for  the  first 
time,  a  new  entry  for  the  client  is  created  and  the  channel  is  attached  to  this  entry.  When  a  client 
disconnects  from  the  system,  the  channel  is  closed  and  detached  from  the  enuy  but  the  entry  remains  in  the 
list  even  afta  the  client's  disconnection  to  keep  track  of  the  client's  activity.  When  a  reconnection  or  a 
hand-off  occurs,  the  corre^nding  entry  is  updated. 

It  is  important  that  a  migration  is  informed  by  a  single  ABCAST  message  to  all  servers.  Ihis  means 
that  a  migr^on  looks  like  an  atomic  (indivisible)  action  to  the  observers.  TUs  atomicity  makes  it  easier 
to  write  a  fault-tolerant  program  since  servos  do  not  need  to  keep  intermediate  states  and  restore  them  for  a 
failure  recovery. 

The  migration  decision  medianism,  which  decides  which  server  should  take  over  which  client,  is 
outside  the  system.  A  decision  is  made  by  location  information  of  a  mobile  client,  usually  by  detecting  the 
signal  levd.  Decision  mechanism  varies  from  system  to  system.  For  example,  decisions  can  be  made  by 
sovers,  by  mobile  clients,  or  by  negotiation  between  a  server  and  a  client.  When  a  backup  saver  is 
instructed  to  be  a  new  primary,  it  invokes  a  channel  switch  to  take  over  the  channel.  The  mechanism  of 
channel  switch  is  disciused  in  the  next  subsection. 


3.2  Channel  Layer 

The  channel  layer  provides  an  abstraction  of  a  communication  channel  which  acts  like  a  reliable  one-to- 
many  FIFO  channel.  The  channel  layer  assumes  some  kind  of  datagram  service  underneath  and  currently 
usesUDP. 

The  channel  mechanism  is  based  on  a  point-toiioint  sliding-window  protocol.  One-to-many 
connection  is  realized  by  replicating  the  sliding-window  state  of  the  primary  to  the  backups.  Whoi  the 
primary  receive  a  message  from  a  mobile  client,  the  primary  forwards  this  incoming  message  to  the 
backups  by  ABCAST  or  CBCAST.  Thus,  all  savers  see  the  same  set  of  incoming  messages  in  the  same 
orda  and  the  input  window  state  of  each  serva  is  kept  identical.  According  to  an  incoming  message,  all 
servos  take  klentical  actions  as  a  state  machine.  Hence,  the  output  window  state  of  each  sovo  is  also  kept 
identical.  When  servers  said  messages  to  a  mobile  client,  only  the  primary  actually  sends  out  messages. 
Each  diannd  on  the  servers  has  a  flag  which  shows  if  the  servo  is  primary  or  not.  The  output  routine 
checks  this  flag  and  if  it  is  not  set,  the  ouQmt  routine  does  nothing.  The  mobile  view  layo  is  responsible 
to  mainrain  at  most  One  primary  po  client  at  one  time.  Outgoing  messages  in  the  output  buffer  of  each 
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server  are  discarded  when  the  corresponding  acknowledgment  is  forwarded  from  the  primary.  Those  delayed 
acknowledgments  are  piggybacked  in  incoming  messages. 

To  keep  the  output  windows  consistent,  it  is  essential  that  all  servers  take  identical  actions.  For  a 
same  set  of  incoming  messages,  a  deterministic  action  suffices.  Two  other  event  sources  should  be 
mentioned  which  may  affect  deterministic  actions.  One  is  a  timer.  A  timer  produces  events  local  to  the 
machine  and  the  sliding-window  requires  timeouts  for  delayed  acknowledgments  or  reu'ansmission. 

However,  sending  acknowledgments  or  retransmission  does  not  change  the  window  state.  Hence,  timer 
events  of  the  sliding-window  mechanism  do  not  affect  the  determinism.  The  other  is  scheduling.  Even 
when  a  server's  action  blocks,  ordering  of  actions  should  not  be  changed  at  all  servers.  The  ISIS  scheduler 
employs  a  strict  FIFO  order  scheduling,  and  unblocking  is  triggered  only  by  ordered  events.  .\s  a  result, 
blocked  actions  resume  in  the  same  order  at  all  servers  and  the  scheduling  does  not  affect  the  determinism 
either. 

Client  programs  can  specify  either  ABCAST  or  CBCAST  to  forward  a  message  from  the  primary  to 
the  backups.  When  a  message  changes  some  state  shared  with  other  mobile  clients,  ABCAST  should  be 
used  in  order  to  guarantee  the  total  delivery  order. 

When  a  mobile  client  becomes  unreachable,  the  channel  tries  retransmission  with  exponential 
back-off  then  informs  the  upper  layo*  of  the  channel  state  change,  but  never  drops  the  connection  unless  the 
client  establishes  a  new  connection.  Send  operations  will  block  when  the  output  buffer  is  full.  Servers 
have  a  fairly  large  output  buffer  to  tolerate  transitory  unreachability  for  a  diffusion  style  communication. 
The  details  of  the  mechanism  is  discussed  in  the  next  subsection. 

The  connection  management  is  based  on  the  TCP  model  that  is  defined  as  a  finite  state  machine 
[PostelSl].  The  connection  establishment  and  termination  mechanisms  are  the  same  as  TCP.  To  ‘support  a 
channel  switch  between  servers,  a  special  flag  "SWITCH"  is  defmed  in  a  packet  heado-.  When  a  primary 
receive  a  migration  request,  it  clears  the  primary  fl^  and  multicasts  a  primary  switch  command  specifying  a 
new  primary.  Upon  receiving  this  command,  the  new  primary  sets  the  primary  flag  in  the  channel  entry 
and  sends  a  SWITCH  segment  to  the  client  specifying  the  port  number  of  the  new  primary.  Upon  receiving 
this  SWITCH  segment,  the  client  updates  the  address  and  port  number  of  the  peer.  The  acknowledgment  of 
the  SWITCH  segment  is  processed  in  dte  same  manner  as  ordinary  packets.  Figure  3.1  presents  the 
primary  switch  procedure. 


In  a  channel  switch  procedure,  the  sliding-window  states,  including  sequence  numbers  and  buffered 
messages,  of  both  ends  are  not  initialized  and  remained  intact.  Thus,  both  ends  can  continue 
communication  from  the  same  state  just  before  the  channel  switch.  The  only  difference  is  the  primary  flag 
on  the  previous  and  current  primary  servers,  and  the  peer  address  and  port  number  on  the  client. 

Ihere  is  a  small  timing  gap  between  clearing  the  primary  flag  by  the  current  primary  and  setting  the 
flag  by  the  new  primary,  «diere  no  server  has  a  primary  flag  set.  Packet  loss  or  duplicates  may  occur  during 
this  period,  but  the  quick  switching  mechanism  narrows  the  possibility  and  those  errors  are  suppressed  by 
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L'le  sliding-window  mechanism.  Note  that  sending  a  primary  switch  command  from  a  current  primary  to  a 
new  primary  creates  a  causa]  chain;  message  forwarding  by  the  primary  is  thus  FIFO  ordered  by  CBCAST 
even  in  the  {»-esence  of  primary  switch. 

One  might  concern  about  the  increase  of  message  traffic  caused  by  the  sliding-window  replication  but 
the  increase  of  message  traffic  is  surprisingly  small.  The  replication  scheme  forwards  only  incoming 
messages.  Most  of  incoming  messages  will  be  for  data  updates,  since  most  read  operations  will  be  a  one¬ 
way  difhision  style  from  a  server  to  a  client.  Even  without  the  sliding-window  replication,  it  is  necessary 
to  multicast  updates.  Thus,  increase  of  message  traffic  comes  basically  from  ack  packets.  The  mechanism 
of  delaying  and  piggybacking  acknowledgments  in  the  sliding-window  protocol  works  well  under  heavy 
traffic.  Ack  packets  are  much  fewer  than  data  packets  because  of  the  delayed  ack  mechanism.  In  addition, 
ack  packets  can  be  forwarded  by  cheaper  CBCAST  beouise  the  window  state  is  local  to  the  client.  As  a 
whole,  the  increase  of  message  traffic  is  negligible. 

Another  concern  would  be  state  transfer  at  joining  a  group.  When  a  new  process  joins  a  group,  the 
entire  sliding-window  state  including  buffered  messages  should  be  transferred  by  the  ISIS  state  transfer 
mechanism.  Nevertheless,  the  sliding-window  normally  holds  zero  or  less  than  a  few  messages,  and  ISIS 
tries  to  pack  multiple  message  into  one  for  efficiency. 

One  restriction  with  regard  to  the  state  transfer  of  the  sliding-window  is  that  no  thread  ^ould  be 
waiting  to  write  to  the  channel  at  a  state  transfer.  The  state  transfer  sends  out  the  sliding-window  state  but 
it  cannot  send  the  states  of  blocked  threads.  To  avoid  this  situation,  MobileChannel  inhibits  joining  a 
group  while  a  write  is  blocked. 

For  a  security  reason,  a  32-bit  connection  key  is  created  at  a  connection  establishment.  To  take  over 
the  channel,  this  key  must  be  replicated  to  backup  servers  and  a  backup  needs  to  send  this  connection  key  in 
the  SWITCH  segment. 


3.3  Utilities 

The  following  utilities  are  implemented  to  support  programming. 

3.3.1  RPC  style  and  Diffusion  style  Communication 

Although  the  channel  layer  provides  a  reliable  channel,  MobileChannel  also  provides  a  simplified 
inteifsu:e.  MobileChannel  directly  siqtports  the  RPC  style  and  the  diffusion  style  of  communication.  In  the 
RPC  style,  a  client  blocks  until  tte  corre^nding  rqtly  comes  back.  The  server  callback  provides  a  way  to 
send  a  reply  to  the  requester.  In  die  diffusion  style  communication,  a  single  call  on  the  server  side  sends  a 
message  to  all  clients.  Most  applications  will  use  a  mixture  of  the  above  two  styles. 

The  diffusion  style  needs  a  qtecial  data  flow  control.  Since  messages  are  usually  generated  unrelated  to 
the  states  of  clients,  data  flow  does  not  stop  even  when  a  client  is  unreachable  so  that  a  point-to-point  flow 
control  scheme  does  not  woik  well. 

The  two  styles  behave  differently  vriten  the  ouqnit  bufrer  is  full.  In  the  MobileChannel  sliding-window 
mechanism,  vibea  the  output  buffer  is  full,  said  blocks  until  a  slot  becomes  available.  However,  in  a 
diffusion  communication,  it  is  possible  that  blocked  send  q;)erations  pile  up  during  the  client  is  temporarily 
umeachaUe.  Though  applications  can  specify  the  ouqmt  buffer  size  according  to  their  demand,  dynamic 
message  traffic  and  unieaduble  duration  are  unpredicUdile.  In  addition,  a  blocked  send  prevents  a  new  server 
from  johiing  the  group  as  discussed  in  Section  3.2.  To  avoid  fliis  situation,  the  diffusion  mechanism 
inqilements  the  following  scheme:  vriien  die  output  buffer  is  full,  a  diffusion  send  just  discards  the 
message  and  maria  die  message  overflow,  and  vriien  a  slot  becomes  available,  the  system  notifies  the 
application  about  die  ovoflow.  It  is  applications'  r^ionsibiliiy  to  take  an  qqiropriate  action.  For  most 
applications,  reinitializing  the  client's  state  by  sending  the  current  state  saved  at  the  server  will  be  oiough. 
Even  sriien  Affusion  messages  are  being  Ascarded,  however,  a  RPC  reply  is  neva  lost.  An  alternative 
schdne  is  to  inqilement  an  infinite  backlog  as  ISIS  News  does  [BirmanST].  This  scheme,  however,  may 
cause  an  unfiivmable  flood  of  messages  when  the  communicadon  is  restored. 

The  design  of  MobileChannel  assumes  applications  for  qierational  clients.  MobileChannel  does  not 
direcdy  support  the  delivery  guarantee:  everyone  receives  a  message  even  Mien  it  is  disconnected  for  a  long 
time.  If  an  qiplicationreqttiiesaodi  a  guarantee,  the  best  way  is  to  use  ISIS  News  within  servers.  ISIS 
News  implements  publish  /  subscribe  schemes  by  means  of  virtually  infiAte  backlogs. 
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3.3.2  Primary  Actions 

In  MobileChannel,  it  is  common  that  all  servers  take  the  same  action  corresponding  to  an  event. 
However,  it  is  sometimes  necessary  that  only  a  primary  takes  an  action,  especially  for  hierarchical  groups. 
To  make  such  an  action  fault-tolerant  is  not  as  easy  as  it  seems  at  first.  When  the  action  has  some  side 
effect,  such  as  sending  a  message,  the  action  should  be  executed  exactly-once.  If  the  primary  fails  in  the 
middle  of  the  action,  the  backups  could  not  tell  if  the  primary  fails  before  or  after  sending  the  message.  The 
Primary  Action  mechanism  supptnts  these  programming  models  by  using  the  ISIS  coordinator-cohort 
mechanism.  The  coordinator-cohort  scheme  supports  a  computation  in  which  an  elected  coordinator 
conducts  the  compuution  in  a  fault-tolerant  manner. 


3.3.3  Mobile  Monitor 

The  Mobile  Monitor  mechanism  provides  a  way  to  monitor  state  changes  of  servers  and  clients.  A 
client  can  be  notified  when  a  server  joins  or  leaves  the  group,  or  other  clients  change  their  states.  Three 
client  states  are  defined:  connected,  disconnected  and  temporarily  unreachable. 


4  Current  Status 

4.1  System  Environment 

The  current  system  environment  is  as  follows;  Ihe  server  machines  are  SUN  SparcStations.  The 
client  machines  are  subnote  PCs  (40MHz  486DX2  and  8M  RAM)  running  Microsoft  Windows3.1,  a 
desktop  PC  rtuining  WindowsNT3.1  and  SparcStaions  running  SunOS4.1.1.  The  subnote  PCs  are 
equipped  with  NCR  WaveLAN  PCMCIA  wireless  Ethernet  cards  (2Mbps)  and  can  talk  to  the  servers 
ttvough  a  bridge.  The  other  client  machines  and  serv^  are  hooked  up  to  a  10Mbps  Ethernet.  We  do  not 
have  a  device  to  locate  mobile  clients  nor  a  wireless  device  capable  of  cell  hand-o^  so  that  migration  is 
triggered  by  an  emulator  and  the  wireless  clients  are  physically  in  a  single  cell. 

The  MolnleChannel  server  library  runs  on  top  of  ISIS.  ISIS  runs  on  most  UNIX  based  platforms  and 
WindowsNT.  The  client  library  runs  on  the  X  Window  System /UNIX  or  Microsoft  Windows.  The 
interface  of  Microsoft  Windows  uses  the  WIN32S  API  and  Winsock  vl.l  so  that  it  runs  on  both 
WindowsNT3.1  and  Windows3.1.  The  MobileChannel  client  library  consumes  70K  bytes  on  Microsoft 
Windows  and  the  ISIS  message  library  consumes  another  60K  bytes. 

We  have  built  demo  applications  with  a  graphical  usm-'interface.  The  "reserve"  application  inaplements 
a  train  ticket  reservation  sy^m  and  uses  a  difft^on  style  communication  to  monitor  the  reservation  stams 
and  a  RPC  style  communication  to  make  reservations.  The  "grid”  application  shows  the  througlqnit  of 
MobileChannel. 


4.2  Performance 

The  following  dvoughputs  of  the  prototype  were  measured  with  Sun  SparcStationl  workstations  on  an 
ordinarily  loaded  Ethernet  The  data  in  paroidieses  were  measured  widi  the  subnote  PC  climts  via  the 
wireless  netwmk  and  about  twice  slowo*  dian  the  Sparcstadons  due  to  the  lower  bandwidth,  die  presence  of 
die  bridge,  die  differaice  of  byte  order  and  the  slower  CPU.  Table  1  presents  performance  of  die  diffusion 
style  in  s^ich  one-way  messages  are  continuously  sat  ft-om  a  server  to  a  client  Table  2  presents 
performance  of  the  RTC  style  in  sridch  a  request  message  fi’om  a  client  is  forwarded  to  rqilicated  servers  by 
ABCAST  and  then  the  client  waits  for  a  mUi  reply  from  the  primary.  The  cost  of  die  RPC  style  to 
replicated  servers  is  governed  by  the  cost  of  ISIS  multicast  that  grows  roughly  linearly  widi  the  size  of  a 
groiqi  [Binnaa91].  The  dirougtqiuts  include  creation  /  deletion  of  ISIS  style  messages  that  support 
manthalling  /  MniMndialling  complex  data  Structures. 

A  hand-off  time  is  typically  less  than  20  ms  in  MobileChannel.  A  hand-off  time  can  be  ctefined  as  a 
rime  between  recdving  a  migration  request  by  a  primary  and  switching  the  channel  to  a  new  primary  by  die 
client  One  ISIS  ABCAST  message  for  a  primary  switch  command  and  one  channel  message  for  a  channel 
switch  s^ment  are  required.  ABCAST  costs  less  than  10  ms  for  four  servers  and  a  channel  switch  segment 
costs  less  than  5  ms,  provided  that  no  message  loss  occurs. 
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user  data  size 
(bytes) 

4 

— 

64 

1024 

throughput 

429 

408 

300 

(messages  /  sec) 

(220) 

(204) 

(127) 

Table  1  Diffusion  Throughput 


user  data  size 
(bytes) 

4 

64 

1024 

1  server 

123 

122 

106 

(rpcs  /  sec) 

(56) 

(58) 

(40) 

2  replicated  servers 

85 

95 

77 

(rpcs  /  sec) 

(54) 

(53) 

(37) 

4  replicated  servers 

75 

73 

60 

(rpcs /sec) 

(45) 

(41) 

(31) 

Table  2  RPC  Throughput 


5  Conclusion 

We  presented  a  mobile  support  facility,  MobileChannel,  for  the  ISIS  system.  MobileChannel 
employs  a  unique  scheme  of  a  combination  of  state  rq>lication  and  intentional  primary  switch  to  support 
mobility  of  users.  This  scheme  practically  eliminates  hand-off  protocols  and  hand-off  time  yet  provides 
fault-tolerance.  The  scheme  fits  well  into  the  current  static  network  environmoit  and  progranuning  model, 
and  is  easily  built  on  the  current  technologies. 

As  computer  and  network  teduologies  are  rtpdly  evolving,  expanding  and  diversifying,  the  idea  of 
cooperating  process  grotqis  is  increasing  its  importance.  MobileChannel  is  an  example  how  group 
communication  can  be  used  in  support  of  small  hand-^d  devices.  Replication  is  enq)loyed  to  provide  a 
sinqtle  abstraction  of  migration  as  switching  a  control  point  between  consistent  replicas.  Simple 
abstractions,  provided  by  a  well-oigineered  infrastructure,  will  be  essential  to  attack  chaUenging  new  fields. 
Our  experioice  suggests  Out  serva  replication  will  be  a  sinq)le  but  powerful  abstraction  in  mobile 
cooqmting  for  development  of  robust  and  sophisticated  applications. 
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Appendix:  Programming  Interface 

The  following  sample  code  shows  a  MobileChannel  database  service  for  maintaining  a  mapping 
from  names  (ascii  string)  to  salaries.  The  code  is  derived  from  the  sample  in  [Birman93]. 


/* 

*  sairple  client  of  the  sinple  database  service 
*/ 

finclude  ‘MobileChannel .h* 

tdefine  UPDATE  1  /*  entry  number  for  update  */ 

♦define  QUERY  2  /*  entry  nunfcer  for  query  •/ 

tdefine  SIMPLE_DB  1  /*  application  type  •/ 


void  maintint  argc,  char  **argv) 

{ 

McStruct  *incp;  /*  pointer  to  a  mobile  channel  structure  */ 

/*  first,  create  a  channel,  then  connect  to  a  server  */ 
mcp  =  MeClatCreate  ( )  ,- 

MeClatCooneettmcp,  ov_name,  SZMPLELbB,  server_na]ne,  server_port)  ; 

...  /*  do  some  li^t  process  to  c^0.1  update  or  query  *! 

I*  disconnect  from  the  server,  then  close  the  channel  */ 
MeClatDlseenaeet (mcp) ; 


/*  send  qpdate  uslnq  about  */ 

void  i^xlate  (McStruct  *mcp,  char  *naB»,  Int  salary) 

{ 

lioCIntMtqat (mcp,  XiPDATE,  *%s,  %d*,  name,  salary); 

) 

/*  aslc  for  a  salary  value  using  rpc  */ 
void  query  (IfcStxuct  *incp,  char  *name) 

{ 

int  salary; 

NeClBtXK  (mcp,  QUERY.  '%s*,  name,  *%d*.  Asalziry)  ; 
retium  (salary)  ; 
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*  sanpla  server  of  the  slsple  dataOaase  service 
*/ 

Sinclude  'MoblleChannel .h' 

♦include  'mss.h*  /•  for  mobile-support-station  */ 

♦define  UPDA.TE  1  /*  entry  niaitoer  for  update  •/ 

♦define  QUERY  2  /*  entry  nuznber  for  query  */ 

void  malndnt  argc,  char  “argv) 

{ 

isis_reoiote_init{NULL,  0,  0,  0);  /»  initialize  isis  •/ 

/*  set  callbacks  for  channel  entries  */ 
lIeAddCallbaek( UPDATE,  update); 

NeAddCallbaek ( QUERY ,  query ) ; 

/*  set  callbacks  for  state  transfer  *! 
■■•_«dd_eallbaek(MSSEC_SEMD_XFER,  send_state) ; 
■■B_aid4_oallbaek(MSSEC_RECV_XFER,  recv_state) ; 

/*  mssjnalntask  Is  a  built-in  raoblle-siq^port-station  task  that 
joins  a  inss_groi;p  and  manages  mobile  clients  and  channels  */ 
lsls_inaln^loop(assjBslntaslt,  NULL)  ; 

/*  never  returns  */ 


/•  callback  for  entry  UPDATE  *! 
void  vqxiate  (HcStruct  *mcp,  massage  *iip) 

( 

char  name [32] ; 

Int  salary; 

msQ  aettmp.  *t8,%d*,  name,  Rsalary); 

8et_salaty(name,  salary) ;  /*  update  the  database  locally  */ 


/*  cedlback  for  entry  QUERY  */ 
void  query  (HcStruct  *mcp,  message  *np) 

( 

char  name [32]; 
int  sedary; 

insgjgat(ap.  •%8*,  name)  ; 

salary  *  get_8alazy(naine) ;  /*  get  salary  value  by  name  *! 

NeSvcWCaeplirCmcp,  *%d*,  salary);  /*  reply  to  the  client  */ 


/*  send  out  dataibase  state  */ 
void  8eiiid_8tate(int  locator) 

( 

struct  sdb_entry  *sp; 

for  (ap  ^  haadCsdb);  SP  tall(sdb);  sp  =  q>->s_next) 
xfer_out(*%8,  %d*,  Q>->sjaaB»,  8p->s_salary) ; 

) 

/*  receive  state  at  pgiJoln  */ 

void  racv_8tate  (int  locator,  massage  *iip) 

{ 


update  (NDUi,  up) ; 


